huge.hoo
변경되지 않는 이미지, CloudFront가 수상하다
Mar 03, 2025

Table of Contents

    들어가는 글

    간단한 운영 이슈 기록
    현재 운영중인 제품은 마케팅 캠페인을 제공하는 SaaS 로 고객사 서비스에 유저들이 인게이지 할 수 있도록 서비스, 쉽게 생각하면 다양한 미니 게임을 제공합니다. 미니게임을 이루는 요소엔 다양한 이미지가 포함되어 있는데 이 이미지가 CDN 에 캐싱되어 헤맸던 이슈를 기록으로 남겨보았습니다.

    S3의 이미지 직접 수정

    고객사에서 상용에 라이브하기 전 테스트하는 중 캠페인에 사용될 이미지 수정 요청을 받았습니다. 이미 생성된 캠페인은 어드민 페이지에서 이미지를 수정할 수 없도록 막은 정책이 있어, 개발자가 직접 이미지를 수정해야 했습니다. 현재 시스템의 이미지 파일은 S3 에 저장되어 있고, 해당 이미지의 주소를 DB 에 저장하여 이미지를 사용하는 방식으로 운영되고 있습니다.

    DB 에 저장된 이미지 주소를 변경하기엔, 여러 필드에서 동일한 주소를 참조하는 곳이 많았습니다. 이런 경우엔 해당 이미지의 주소는 그대로 사용하되, 이미지 객체만 변경하는 것이 낫다고 판단하여 s3 에 저장된 이미지 객체를 변경(덮어쓰기) 하는 방법을 선택했습니다.

    // 기존 이미지 오브젝트
s3://bucket-name/image-header.png

// 변경해야할 이미지 오브젝트 -> 기존의 오브젝트를 덮어씀
s3://bucket-name/image-header.png

    가령 s3 bucket 에 image-for-header, image-for-footer 라는 기존 오브젝트가 있으면, 변경해야할 이미지를 동일한 이름으로 업로드 하는 방식입니다.

    이렇게 하면 DB 의 여러군데에서 참조중인 이미지를 일일이 수정할 필요가 없습니다.

    어드민 페이지에서 해당 켐페인의 이미지가 수정된 것 까지 확인됐습니다. 이미지가 잘 변경되었다고 생각하여 운영매니저 분께 연락을 남겼고, 저는 오후 반차로 이른 퇴근을 하게 됩니다.

    헤치웠나..?

    💭 "이미지 그대로 라는데요 ?"
    ktx 에서 졸면서 내려가던 중 슬랙 알람에 벌떡 놀라 일어났습니다. 이미지가 변경되지 않아서 고객사에서 다시 연락이 왔다는 것입니다. 분명 브라우저 캐시 삭제 후 어드민 페이지에서 이미지가 변경된 것 까지 확인하고 퇴근했는데 왜..? 퇴근 직전 불현듯 시니어 개발자 분께서 'cdn 에 캐싱되어 있을수도..' 말을 하신 것이 생각났습니다.
    설마 진짜 cdn 때문인가? 저희 서비스는 AWS 에서 제공하는 CloudFront 를 사용하고 있어 CloudFront 를 확인해야 겠다고 생각했는데.. 정말 감사하고 죄송하게도 제가 기차에서 조는 동안 시니어 개발자 분께서 문제 원인 파악까지 끝내고 CloudFront에 캐시 무효화까지 해두셨습니다. 실제로 CloudFront 캐시 Invalidation 을 실행하니 고객사 측에서 변경된 이미지가 잘 나온다는 연락을 주셨습니다. image3

    상황을 간단히 나타내면 위 그림과 같습니다. s3 의 이미지 오브젝트를 변경했지만, 기존 이미지 오브젝트와 동일한 이름을 사용했기 때문에 CloudFront 에서 이를 캐싱하여 변경된 이미지가 제공되지 않았던 것입니다.


    AWS CloudFront란?

    CloudFront는 AWS에서 제공하는 CDN(Content Delivery Network) 서비스입니다. CDN은 전 세계에 분산된 엣지 로케이션을 통해 콘텐츠를 캐싱하고 제공함으로써, 최종 사용자에게 더 빠른 콘텐츠 전송을 가능하게 합니다. 현재 저희 서비스는 고객사 애플리케이션에 서빙하는 이미지 콘텐츠를 CloudFront 에서 캐싱하여 제공하고 있습니다.

    CloudFront의 주요 특징:

    1. 글로벌 엣지 로케이션: 전 세계 여러 지역에 위치한 엣지 서버를 통해 사용자와 가까운 위치에서 콘텐츠를 제공
    2. 캐싱: 자주 요청되는 콘텐츠를 엣지 로케이션에 캐싱하여 오리진 서버의 부하 감소
    3. 보안: HTTPS 지원 및 DDoS 방어 기능 제공

    캐시 무효화가 필요한 이유

    CloudFront는 설정된 TTL(Time To Live) 동안 콘텐츠를 캐싱합니다. 따라서 Origin(이 경우 S3)의 콘텐츠가 변경되더라도, TTL이 만료되기 전까지는 이전 버전의 콘텐츠가 계속 제공될 수 있습니다. 이런 경우 수동으로 캐시를 무효화(invalidation)해야 새로운 콘텐츠가 즉시 반영됩니다.

    수동으로 CloudFront 캐시 무효화하기

    기존 이미지(ex, image.png)를 새로운 이미지(동일 이름 image.png)로 오버라이드 했음에도, cdn 에 캐싱되어 있는 이미지가 변경되지 않았던 것이 이슈의 원인이었습니다. cloudfront 을 확인해보니 당일 invalidation 기록이 남아있었습니다. 시니어분께서 조치하신 흔적이었습니다.

    image1


    추후에도 이런 일이 발생할 수 있어 캐시 무효화 방법을 알아보았는데, 생각보다 간단했습니다. creat invalidation 버튼을 클릭하면 해당 cdn distribution 에 캐시 무효화 요청을 보낼 수 있습니다. 아래 이미지처럼 캐시 무효화 하고 싶은 s3 bucket 의 경로를 입력하면 원하는 콘텐츠에 대해서만 캐시 무효화(갱신)를 진행할 수 있습니다.


    image2

    마무리

    이번 이슈로 필요하로 수동으로 CloudFront 의 캐시 무효화를 할 수 있다는걸 배울 수 있었습니다. 사실 이전까지 CDN 에 직접 접속할 일이 없어서 CloudFront 가 막연한 상태였는데, 캐시 무효화도 AWS 콘솔에서 버튼 몇 번 누르면 끝나는 간단한 작업이었습니다. 앞으로도 비슷한 캐시 관련 문제를 마주쳤을 때는 "이미지나 콘텐츠가 오버라이드 된 것은 아닌지?", "CDN 캐시가 원인일까?" 의심을 먼저 해보는 게 도움이 될 것 같습니다.